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REMARKS/ARGUMENTS 
/. Procedural History of Application and Current Status of the Claims 

In the interests of keeping track of the extensive prosecution in this case, Applicants 
present a brief overview. This application was filed on April 14, 2004. The claims have been 
rejected on the merits four times now, the first time over the same primary references, and most 
recently over a newly cited reference. 

In response to each of the first two rejections, Applicants amended the claims. In 
response to the third rejection, Applicants submitted declarations setting forth secondary 
evidence of non-obviousness. In the fourth office action, no acknowledgement was made of 
those declarations. However, given that the obviousness-based rejections were withdrawn, it is 
presumed that they were considered. 

Now all 32 claims of the application stand rejected as being anticipated by U.S. Patent 
No. 6,181,837 to Cahill. 

Here is a brief overview of the actions in this case: 

• 2007-08-23 Office Action - All claims rejected over Anderson et al. in view of Dutta et 

al. 

• 2007-12-05 Response Filed with Claim Amendment 

• 2008-02-1 1 Final Office Action - All claims rejected over Anderson et al. in view of 

Dutta et al. 

• 2008-04-08 Response Filed 

• 2008-08-1 1 RCE Filed With Supplemental Amendment Suggested by Examiner 

• 2008-10-01 Office Action - All claims rejected over Anderson et al. in view of Dutta et 

al. in further view of De Bonet. 

• 2009-03-3 1 Response Filed with Secondary Evidence Declarations 

• 2009-06-25 Office Action - All claims rejected as anticipated by U.S. Patent No. 

6,181,837 to Cahill 

Claims 1, 15, 21, and 31 have been amended to clarify that the downloadable index 
and/or archive of images is a customer-specific one. Support for this amendment is found in 
paragraphs 0043 and 0044 of the specification. 

Claims 2 and 16 have been amended to further specify incorporating a corresponding 
account statement into the downloadable index. Support for this amendment is found in 
paragraphs 0045 and 0047 of the specification. 

Claim 1 1 has been amended to clarify that the printed check has not yet been presented 
for payment. Support for this amendment is found in Fig. 3 and paragraph 0035. 

Claim 17 has been amended to specify that the financial transaction software program is a 



9 of 21 



Appl. No. 10/824,792 

Amendment and Response dated Aug. 1 8, 2009 
Reply to Office Action of June 25, 2009 

bookkeeping-type program that tracks a running balance of a checking account. Support for this 
amendment is found in Figs. 3 and 7 of the specification and the accompanying description. 

17. Remarks 

Applicants respectfully traverse the rejections. In order to anticipate a claim, a reference 
must teach each and every element of the claim. Cahill does not teach several elements of the 
claims. 

A. Overview of Cahill 

Before identifying the specific elements that Cahill fails to teach, it is instructive to 
understand what Cahill teaches. 

The Cahill patent, filed on Nov. 18, 1994 and assigned to Chase Manhattan Bank, is 
remarkable for its recognition of the very long-felt needs and problems of the prior art. Cahill 
recognizes the difficultly and expense banks and their customers have long faced in organizing, 
accessing, retrieving, and managing cleared checks. But Cahill fell far short of solving those 
problems in an effective manner, much less in the particular manner that Applicants claim. 

In the background section, Cahill observes that "[fjor several decades now the U.S. 
government has ... required that financial institutions maintain a seven year library ... of all 
checks deposited and/or paid from the institution's accounts" (1:32-37). Cahill also notes that 
many bank customers "maintain their own extensive check libraries" (2:15) to accommodate 
requests for proof of payment. Moreover, "[d]ue to the immense volume of stored information, 
the average turn-around time - the time elapsed from when the request is made until the copy is 
received - for fulfilling such requests can vary from a minimum of 24 hours to one to two weeks 
or more" (2:43-48). Accordingly, Cahill recognized - all the way back in 1994 - that "it is 
desirable to provide a system whereby a customer of the banking institution can request, retrieve, 
and display copies of checks, and, preferably, generate correspondence with a copy of a check, 
i.e., a check image, all without bank staff involvement" (3:5-10). 

Cahill was filed after the dawn of the World Wide Web, and 2Vi years after the release of 
Windows 3.1. The Mosaic browser - the first browser to display images inline with text and the 
browser credited with popularizing the World Wide Web - was released in 1993. Windows 3.1 
- the first PC-based graphical user interface to become widely popular - was released in April 
1992. Although Cahill makes no explicit reference to the "Internet," it describes a system in 
which check images are computer sorted by a host system 8 - which includes a sort station 2, an 
image storage station 5, and an output station 6 connected by an apparently internal network 3 - 
over a telephone line 1 1 and modem 10 to a customer workstation 7 (12:42-57; Figs. 1-3) hosting 
Windows' graphical user interface. Cahill clearly attempted to leverage the latest technology to 
deliver cleared check images to customers. 

The elaborate detail in the Cahill patent - including several image screens - suggests that 
a real prototype was reduced to practice. Cahill, however, discloses a cumbersome user interface 
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and check image delivery system that - as explained in further below - fell far short of 
anticipating, much less providing the overall advantages of, the claimed invention. The bottom 
line is that Cahill's system failed to effectively satisfy the long felt needs to which Applicant's 
invention is directed. 

The Cahill system had two very significant shortcomings: it was cumbersome and it was 
inefficient. But Cahill's failure to disclose solutions to these shortcomings is not surprising. 
Identifying, retrieving, transmitting, and organizing check image data - all the while maintaining 
data security - is a very complex, non-trivial process. 1 Truly, nothing is "easy" in this business. 

Cahill disclosed a customer workstation or "image station 7" (12:42-45) comprising a 
computer 701, display device 701A, and a printer 703 (13:33-43). The customer workstation 7 
provides a software-based user interface, including screens that allow the user to "initiate 
requests for check images, download those images to the customer workstation 7, and view or 
print the downloaded images as desired" (32:32-37). 

Cahill's process for downloading a check image is exceptionally cumbersome. It begins 
with the user selecting the "Enter Check Request" menu option, which opens up a check request 
data entry sub-window (35:10-12; 38:15-21; 40:43-45; Figs. 10, 16). Then, the user serially 
enters in check requests - including at least a check number (41 :23-24) - one at a time, into data 
entry fields 350 at the top of a "spread-sheet like screen" shown in Figs. 10 & 16 (40:30-34; 
40:45-62), and confirms each individual check number request by selecting the "Add to List" 
control button 400 (41:31-35). To add the next check number, the user must first clear the data 
entry fields by clicking the "Clear Entry Fields" button 400 and then enter the next check number 
(42:5-7). 



^ Ssiset/Qispioy Check . . . | T---} " "1 \\ 

FIG. 7 

Each time the user enters a check image request, the request is listed in the spread-sheet 



Cahill is notable for its elaborate detail on how cleared checks are sorted, scanned front and back, and processed. 
The process includes sending the check through an MICR reader to read and magnetically decode the MICR line of 
the check; digitally imaging the entire check and OCR'ing at least portions of the check; temporarily storing the 
check images; and merging the decoded MICR data and other metadata together with front and back images of a 
check into a single TIFF file (14:4-15:2). The process also includes an elaborate error-checking, error -repair, and 
sorting system (16:17-22:7). After a sufficient number of TIFF images are accumulated, they are grouped into a 
BLOB file containing as many as 50 or more TIFF files for long-term storage. The BLOB file location of each 
check image is then stored in an index record. Each BLOB file itself includes a header containing data (including 
the starting byte and byte length) locating each check TIFF image within the BLOB file (15:43-67; 27:16-28:65). 
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like section of the screen and recorded in a request file 720 which "contains the most recently 
compiled list of requests for transmission to the host system 8" (34:48-50). 

Later, the user selects the "Send Request File" menu 
option (38:17-24), after which the workstation 7 is connected, 
via modem 10, to the host system 8. The user must then enter 
his user ID and password before the request file is transmitted 
to the host system 8 (22:47-49; 33:14-17; 36:4-67; 44:35-66). 
After sending the request, the communication session is 
terminated (36:65-57), and the "status field" in appropriate 
record 71 1 is updated to "pending" (37:1-4). 

After the host system 8 receives the request file, it adds the requests to a request queue 
601 (22:51-55; Fig. 5C). Over time, the host system 8 reads the queue 601 in a first-in, first-out 
order, determines the location of the check image, and records the location of the requested 
check image in a request data structure (22:63-23:5; Fig. 5C). Next, a different process reads the 
request data structure, retrieves the TIFF image file 22 from the storage device and/or BLOB file 
where it is located, parses the TIFF file 22 into separate front (".f ') and back (".b") image files - 
each retaining meta-data concerning the check data fields - and deposits them into an appropriate 
download directory (23:6-9; 25:45-27:7; 29:11-30:7; 31:31-53). The system also generates 
"Check Not Found" files in a TIFF image format, together with embedded meta-data identifying 
the requested check and account numbers, and deposits those in an appropriate download 
directory (27:8-14; 29:52-56). 

Later, a user initiates a new communication session by selecting the "Get Images From 
Chase" menu option (38:17-31). This option initiates a new communication session between the 
workstation 7. Again, the user is required to enter his user ID and password (45:1-8). After 
successfully navigating through these security barriers for a second time, the host 8 sends a 
request to the host 8 to download previously requested check images. "If no checks have yet 
been retrieved from the archive, the host system transmits a message to inform the workstation 
that no checks are ready to download...." (45:17-20). If files are available for download, the 
host 8 notifies the user of their availability and the size of transmission and requests confirmation 
(37:8-14). If the request is confirmed, the host 8 transmits the files - one at a time - to the 
workstation using the Z-modem protocol (37:8-58; 45:9-44). 

After the front and back check images are downloaded to the workstation 7, the 
workstation logs off, indicates that the download is completed, and prompts an "updating local 
database" message (45:44-52). During the updating process, the software scans each newly 
retrieved front and back TIFF image to extract the metadata about the check, including the 
account and check number. The workstation software then stores the extracted information in a 
main database file 710. The database file 710 contains a record 711 for each cleared check that 
has been requested or received, including the check number, amount, date, status, and front and 
back image file names (34:41-45; 35:17-38). Then, the front and back images are stored in an 
image subdirectory 702B (34:39-45; 35:44-46). The images are retained for a period of 
"between 1 and 31 days" before it appears on a "deletion list" (49:23-32; Fig. 23). 
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After the downloading procedure is complete, the workstation 7 returns the user to the 
main menu (Fig. 7). If the user selects the "Select/Display Check Image" menu option, the 
workstation produces the "Select/Display Check Images Screen" of Fig. 11. 




FIG. 11 HG. 17 



Fig. 1 1 displays a sortable spreadsheet-like list of every check for which a check image 
request has been submitted, together with "information pertaining to that request" (45:61-63). 
The user can select one of the rows, and then press "Enter" key, causing a new display sub- 
window, shown in Fig. 17, to be launched to display the front and back check images (46:43-54). 

Although Cahill is preoccupied with enabling an online-check-requesting system that is 
limited to manually entered requests for images of one cleared check at a time, Cahill does 
disclose a method for bulk export of check images. In particular, Cahill discloses an "export 
station 610" with a "bulk export controller" that can write check images to a suitable computer 
readable medium, such as a tape drive or CD, "for the large scale delivery or transmission of 
check images to customers who must process requests for large numbers of checks or who 
require ... that all checks paid by them be provided to them" (13:59-14:3; 30:38-50). Indeed, 
this is still the way most banks deliver check images to their high-check-volume customers. 2 

In summary, Cahill 's system is overly cumbersome. It requires users to enter check 
requests serially {but see fn 2); log on; enter their user ID and password; transmit a check request 
file; log off; wait for the host 8 to process the request; log back on; re-enter their user ID and 
password; and then download the check images. 

Cahill 's system is also inefficient. It describes a process in which front and back check 
images are generated, merged into a single TIFF file, further merged into a BLOB file, indexed 
by the host system 8, then extracted from the BLOB file, split into front and back check images 



2 Cahill does - ever so briefly and apparently as an afterthought - suggest that check images could be downloaded in 
bulk, without a request (46:14-16), or based on a "standing order" (4:25-27; 6:24-29), but Cahill does not explain 
how such an order would be initiated or how such a transaction would be processed. There is no hint of this 
functionality in either the screenshots displayed in the Cahill patent, or in any of the menu options described in 
columns 38 and 39. Cahill made no attempt to provide an enabling disclosure for this nontrivial concept. 
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again, and transmitted serially to the customer's workstation. Then, the workstation re-indexes 
the check images and incorporates them into a new local database. 

B. Cahill does not teach the following elements of the claims: 

1. Cahill does not generate a downloadable archive or searchable index 
of cleared paper check images 

Cahill does not teach providing a software program to a financial institution for use on a 
first computer serving the institution, the software program being operable to generate a 
downloadable customer-specific archive of cleared paper check images and/or searchable index 
of those checks (claims 1, 15, 21, 31). 

The Examiner asserts that Cahill teaches this element at 2:16-40. But in fact, 2:16-40 
only discusses how financial institutions frequently maintain physical archives of checks in 
microfilm. 

The Examiner might have cited 5:19-21 's "electronic host archive storage and retrieval 
system for storing and retrieving copies of checks or check images." But Cahill clearly does not 
teach generating downloadable customer-specific archives or search indices of the check images. 

Rather, Cahill teaches generating large BLOBs of TIFF files as check images are scanned 
in (14:58-15:67) and generating a massive index of all the cleared checks. Accordingly, both the 
BLOBs and the index will ordinarily span multiple customer accounts. 

Moreover - as discussed in the Cahill summary - Cahill teaches transmitting front and 
back check images serially, as individual files, one at a time. Cahill does not teach generating a 
downloadable archive of those checks. 

Cahill also does not teach generating downloadable searchable customer-specific indices 
of cleared checks. Rather, Cahill teaches having the customer-level workstation generate and/or 
update a database after the individual check images have been downloaded. 

2. Cahill does not teach providing customers with complementary 
software that downloads archives and searchable indices of cleared 
paper check images. 

Cahill also does not teach providing customers with complementary software that 
downloads archives and/or searchable indices of cleared paper check images (claims 1, 15). 

The Examiner asserts that Cahill teaches this element at 5:21-6:30. But in fact, as 
explained in the extensive Cahill summary above, Cahill teaches downloading individual front 
and back check images, serially, one at a time. Cahill also does not teach downloading 
searchable indices of the check images. 
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3. Cahill does not teach providing a transaction bookkeeping software 
program for use on a computer that includes a checking account 
ledger for recording the customer's checking account transactions. 

The Examiner's office action doesn't even acknowledge the special limitations of claim 
6, which includes providing the checking account customer with a transaction bookkeeping 
software program for use on a computer that includes a checking account ledger for recording 
the customer's checking account transactions. 

Related limitations also appear in claims 17, 25 and 26. Claim 17 recites "a financial 
transaction bookkeeping software program residing on the customer's personal computer, the 
financial transaction bookkeeping software program being operable to maintain a database of the 
customer's financial transactions and track a running balance of a checking account, the financial 
transaction software program being further operable to store the downloaded index together with 
the cleared check images; wherein the index downloading software module is integrated with the 
financial transaction software program." 

Claim 25 recites that "the computer program is a financial bookkeeping software program 
operable to maintain a record of all account transactions affecting the customer's account's 
balance in an account register." Claim 25 depends from claim 24, which recites "providing the 
account customer with a computer program...." Claim 26 depends from claim 25 and recites 
"wherein the financial bookkeeping software program associates the downloaded cleared check 
images with an associated account transaction in the account register." 

A ledger is a record of transactions and/or accounts, each recorded individually with its 
balance. Cahill's workstation system (see Fig. 11, a few pages back) is not a financial 
bookkeeping system. It is does not include a checking account ledger that tracks the balance in 
the checking account. Rather, Cahill's workstation system simply reports the amounts of a few 
checks that have been individually selected for download. 

A similar limitation appears in claim 4, which recites "providing the customer with a 
checking account ledger for recording the customer's checking account transactions; wherein the 
complementary software is operable to record financial transactions in the checking account 
ledger corresponding to the check images in the downloadable index." 

The Examiner asserts that Cahill's Fig. 5 (reproduced below) discloses the limitations of 
claim 4. 
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FIG. 5 



Cahill clearly discloses that Fig. 5 is a "detailed diagram of one embodiment of part of the host 
system showing how check images are stored in/retrieved from the mass storage device of the 
host archive system." (11:15-18). This host system serves and maintains a database of check 
images and corresponding account, check, and amount numbers for all of the bank's customers 
and accounts. This host system is not a bookkeeping system or checking account ledger for 
customers. 



4. Cahill does not teach incorporating multiple cleared paper checks into 
a single downloadable file. 



Cahill does not teach incorporating multiple cleared 
paper check images into a downloadable index (claim 2) or 
into a downloadable single file archive (claim 16). Nor does 
it teach providing downloadable digital archives where each 
archive contains the images of multiple cleared paper checks 
(claims 1, 15,21,31). 



The Examiner asserts that Fig. 27 of Cahill "teaches 
archive of images of multiple cleared paper checks is 
incorporated into the downloadable index." Fig. 27 is 
reproduced to the right. There is nothing either in Fig. 27 or 
the accompanying description to support the Examiner's 
assertion. In fact, the accompanying description (35:17-52) 
reiterates that separate front and back check images are 
downloaded serially, one at a time. 
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5. Cahill does not teach incorporating a corresponding account 
statement into the downloadable index 

Cahill does not teach incorporating a corresponding account statement into the 
downloadable index. This is a newly added limitation to claims 2 and 16, so the Examiner has 
not yet had the opportunity to review this limitation. 

6. Cahill does not teach "comparing the prerecorded information with 
the downloaded transaction information, and alerting the customer if 
there is a mismatch between the prerecorded information and the 
downloaded transaction information." 

Claim 10 recites that the method further comprises the step of comparing prerecorded 
transaction information with downloaded transaction information and alerting the customer if 
there is a mismatch. 

The Examiner asserts that this limitation is taught by Cahill 54:21-34. 

Cahill 54:21-34 is simply the first few lines of claim 1, and the language therein does not 
remotely suggest this limitation. Elsewhere, Cahill teaches that the non-image tag fields in the 
downloaded TIFF files are used to associate the .f and .b front and back image files with the 
requests (53:56-54:2). But the undersigned could find nothing in Cahill indicating that a 
comparison is made to find a mismatch and alert the customer if a mismatch is found. 

Claim 28 recites a related element: "wherein the financial bookkeeping software program 
is operable to compare information about a cleared check image in a downloaded archive with 
prerecorded information about the cleared check." 

The Examiner refused to even acknowledge the limitations of claim 28 by grouping it 
with claims 18 and 26-27. The Examiner cited only Cahill Fig. 25 against claim 28. Fig. 25, 
shown on the next page, does not disclose the limitations of claim 28. Applicant has also 
searched Cahill and found nothing that would anticipate claim 28. 

6. Cahill does not teach "printing a check through the financial 
transaction bookkeeping software, and prerecording the financial 
transaction based on the information printed on the check." 

Claim 11 recited "printing a check through the financial transaction bookkeeping 
software, and prerecording the financial transaction based on the information printed on the 
check." 

The Examiner asserts that this limitation is taught by Cahill at 38:32-35 and Fig. 27. 

The passage at 38:37-38 discloses a "Print Check Image" option, but this option only 
enables printing of a cleared check image. 
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Applicants have amended claim 1 1 to clarify that the check "has not yet been presented 
for payment." Support for this amendment is found in Fig. 3 and paragraph 0035. 

7. Cahill does not teach "receiving an image of a check before it has 
cleared; running an optical character recognition process on the 
check image to identify transactional textual information on the check 
image; and prerecording the financial transaction corresponding to 
the check by storing the optically-recognized transactional textual 
information in the customer's checking account ledger." 

Claim 12 recites: "receiving an image of a check 
before it has cleared; running an optical character 
recognition process on the check image to identify 
transactional textual information on the check image; and 
prerecording the financial transaction corresponding to the 
check by storing the optically-recognized transactional 
textual information in the customer's checking account 
ledger." 

The Examiner asserts that Cahill Fig. 25 recites 
this element. But Fig. 25 is simply a printout of a cleared 
check. Cahill Fig. 25 does not anticipate claim 12. 

Cahill 14:22-67 discusses OCR'ing cleared checks 
as part of the bank's cleared check imaging process. But 
the undersigned could find nothing anywhere in Cahill 
teaching OCR'ing a check before it clears. 

Claim 13 recites a related limitation: "the financial 
transaction bookkeeping software program is integrated 
with an optical character recognition module operable to identify typed or written information in 
a cleared check image." 

The Examiner asserts that Cahill Fig. 27 teaches this element. Fig. 27 discloses neither 
optical character recognition nor a financial transaction bookkeeping software program, much 
less that they are integrated. 



2 CMP - 12th floor 
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8. Cahill does not teach "prerecording a financial transaction 
corresponding to a check; downloading an image of the check after it 
has cleared; running an optical character recognition process on the 
check image to identify typed or written information on the check 
image; comparing the prerecorded information with the optically 
recognized information; and alerting the customer if there is a 
mismatch between the prerecorded information and the optically 
recognized information." 

Claim 14 recites: "prerecording a financial transaction corresponding to a check; 
downloading an image of the check after it has cleared; running an optical character recognition 
process on the check image to identify typed or written information on the check image; 
comparing the prerecorded information with the optically recognized information; and alerting 
the customer if there is a mismatch between the prerecorded information and the optically 
recognized information." 

The Examiner asserts that Cahill Fig. 25 teaches this element. But Fig. 25 is simply a 
printout of a cleared check. Cahill Fig. 25 does not anticipate claim 14. 

7. Cahill does not teach "means for detecting possible check washing 
fraud" 

Claim 20 recites: "means for detecting possible check washing fraud." Corresponding 
structure for this element is set forth in Fig. 3 and the accompanying description of the 
specification. 

The Examiner asserts that Cahill 3:60-63 teaches this element. Cahill 3:53-60 states that 
"It is furthermore an object of the invention to provide at the financial service customer's 
request, a system with the ability on a daily basis to scan a customer's paid checks ... for the 
customer service investigation functions ... [of] signature verification, check fraud evaluation, 
.... etc." 

Cahill is not proposing a system that detects possible fraud on its own. Cahill is simply 
proposing an imaging system to facilitate a customer 's ability to perform a manual "check fraud 
evaluation." Therefore Cahill does not anticipate claim 20. 

8. Cahill does not teach "e-mailing the account customer a notice after a 
digital archive has been generated" 

Claim 22 recites: "e-mailing the account customer a notice after a digital archive has been 
generated." 

The Examiner, by grouping claim 22 with claim 4, did not acknowledge the existence of 
this element. The Examiner impliedly asserted that Cahill teaches this element at Fig. 5. Fig. 5 
does not disclose or teach e-mail. The undersigned searched for the terms "e-mail," "email," 



19 of 21 



Appl. No. 10/824,792 

Amendment and Response dated Aug. 1 8, 2009 
Reply to Office Action of June 25, 2009 

"notice," and "notif*" in Cahill and found nothing that would anticipate this element. 

9. Cahill does not teach that "the e-mail contains a link to a web page 
that enables the account customer to enter a password in order to 
obtain secure online access to the digital archives." 

Claim 23 depends from claim 22 and recites that "the e-mail contains a link to a web 
page that enables the account customer to enter a password in order to obtain secure online 
access to the digital archives." 

The Examiner, by grouping claim 23 with claim 20 ("means for detecting ... fraud"), did 
not acknowledge the existence of this element. The Examiner impliedly asserted that Cahill 
teaches this element at 3:60-63. 

Applicant searched Cahill and found nothing that would anticipate this element. 

10. Cahill does not teach: "providing HTML files to encapsulate the 
cleared check images; generating searchable indexes of the HTML 
files; and incorporating the searchable indexes into the digital 
archives." 

Claim 29 recites: "providing HTML files to encapsulate the cleared check images; 
generating searchable indexes of the HTML files; and incorporating the searchable indexes into 
the digital archives." 

The Examiner did not even acknowledge the limitations of claim 29, instead grouping it 
with claim 19. The Examiner also asserted that Cahill Figs. 25 and 26 recite these elements. 

Cahill doesn't even mention HTML, much less encapsulating cleared check images 
within HTML files. It doesn't mention making searchable indices of HTML files. And it 
doesn't mention incorporating searchable indices into downloadable digital archives. 

177. Conclusion 

Applicants noted this in the previous response and reiterate it here again: the MPEP 
cautions that "it is to the interest of the applicants as a class as well as to that of the public that 
prosecution of an application be confined to as few actions as is consistent with a thorough 
consideration of its merits.''' MPEP § 706.07 (emphasis added). The MPEP also provides that 
"the invention as disclosed and claimed should be thoroughly searched in the first action and the 
references fully applied," and that "[sjwitching . . . from one set of references to another by the 
examiner in rejecting in successive actions claims of substantially the same subject matter, will 
. . . tend to defeat attaining the goal of reaching a clearly defined issue for an early termination, 
i.e., either an allowance of the application or a final rejection." MPEP § 706.07 (emphasis 
added). 
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Applicants respectfully submit that the foregoing arguments are fully responsive to the 
June 25, 2009 Office Action and are sufficient to put the claims in a condition for allowance. 
Should the Examiner desire to sustain any rejections, the courtesy of a telephone conference 
between the Examiner, the Examiner's supervisor, and the undersigned attorney at (719) 689- 
0700 is respectfully requested in advance. 

The undersigned respectfully requests that the application be allowed and passed to issue. 



Respectfully submitted, 



Date: Aug. 18, 2009 

Eric W. Cernyar 
Registration No. 45,919 
Eric W. Cernyar, P.C. 
Hanor, Lively & Cernyar 
750 Rittiman Rd., 
San Antonio, TX 78209 
Phone: (719) 689-0700 
Fax: (719) 325-8318 
eric@cernyar.com 
patents@hanor . com 

ATTORNEYS FOR APPLICANT 
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